標題看似有點難選擇，但有點工作經驗的都能知道正解:

那就是：「我全都要。」XD

而QA工程師作為產品品質的守護者，會有同時追蹤多個問題的需求

並在缺陷修正過後，驗證軟體的最新開發版本是否滿足可以上線的品質。

QA也需要根據測試優先度去思考並安排自己的任務，以因應不同業務需求。

針對Bug/Defect（程式瑕疵），可以列舉出一些日常工作中常用到的工具跟用語：

JIRA

這應該是目前軟體開發中相當有名的專案管理系統，主要用來追蹤Task/Bug

可以知道每個人身上有哪些Case，狀態是還沒做，正在解，需要驗證，已完成。

而當你找到一個Bug的時候，需要敲一個Case給RD來說明你找到的問題是什麼

RD在修完之後，也可以在Case中跟你說他怎麼修的，驗證可以用哪個新版本測試等等

在這邊你可能會聽到多個講法，舉凡敲個Case、開張票(Ticket)、Report Issue等等

這個涉及公司文化跟說法不同，但基本上就是要你在JIRA系統上做Bug的紀錄與追蹤。

而JIRA系統又有以下幾個欄位是可以有效分配時間，提高你的工作效率。

Severity (嚴重程度)

相信大家都有使用手機App的經驗，有時候隨著OS系統的升級

一些很舊沒在更新的App就會開始常常閃退，常常用沒兩下就Crash

像這類會嚴重影響使用者的問題，我們就會把他的嚴重度標示成最高A級

常見的嚴重度等級與例子：

• A級 (Critical)：嚴重影響產品使用，系統支援問題，安全性問題
• B級 (Serious)：功能不符合預期，效能問題
• C級 (Non-critical)：一些UI/Wording問題，不影響功能
• D級 (Enhancement)：不急著這個開發階段修正的小問題

Frequency (發生頻率)

常見的發生頻率等級範例如下（就是英文頻率副詞們）：

• Always （100%）
• Usually (80%)
• Sometimes (50%)
• Seldom (20%)

而Bug發生的頻率，是每個QA跟RD永遠搞不懂的一個謎。

常常QA測到一個Bug，敲了一個P1 Issue，發生頻率寫Always回報給RD後，

RD不管怎麼測，就是測不出問題，這個時候QA常常就會被客訴

但回到QA的環境上面，同樣的問題就能完美重現。

如果你有朋友（或是你本人），常常遇到一些不明的3C問題，也不要太難過

或許就是有成為優秀QA工程師的資質與體質XD

Priority (優先程度)

以上兩點(Severity, Frequency)通常是QA去判斷一個Bug或問題的面向

但最後你都會需要給這個Bug一個Priority，來告訴RD這個有多急要快點修！

而每個人工作時間都很緊繃，一個良好的Priority設定可以讓大家先做最重要的事

一般來說我會這樣粗略地去設定Priority：

其實就是嚴重緊急的先處理，其他細節自己再跟RD評估跟討論決定Priority。

當然，設定Case Priority這件事情也不是這麼硬性規定，存在很多解釋空間

相同Bug也會因為在不同產品開發的階段被發現，而有不一樣的Priority

如果產品快上線Beta前，找到一個修改範圍要很大的Bug，問題又不修不行的時候

原本在Alpha前期可能是P3的bug，因為開發時間只剩一點，可能拉到P1也是有可能的

除了評估一個Bug的影響程度外，同時也要去思考你的軟體開發時程做不做得完。

這點也直接說明了上篇回歸測試在每個軟體開發週期的重要性，

因為越嚴重的問題如果能越早找到，修復問題的時間與人力成本就可以大幅降低。

既然講到Alpha跟Beta

下篇就來提軟體開發週期（Software Release Life Cycle）